1. Field of the Invention
The invention relates to the relocation of header compression/decompression functions between a plurality of network entities and mobile terminals.
2. Description of the Prior Art
Carrying real-time multi-media traffic over IP-based network has become of great interest since the real-time transport protocol has been introduced. Due to the large size of the IP/UDP/RTP header, that is undesirable in low bandwidth networks such as wireless networks, suitable header compression mechanisms are needed. All known RTP header compression techniques require the storing of context information used for compression and decompression of headers of packets at the compressor (transmitter) and decompressor (receiver) and to initialize the compression/decompression process by sending essentially full headers. When header compression/decompression is utilized with a wireless link, headers sent on the uplink traffic are compressed by the mobile terminal and decompressed by a network entity. In the downlink traffic, the network entity compresses the headers, and the mobile terminal decompresses the headers.
In normal operation of compression/decompression, the decompression context information is in synchronism with the compression context information, in the sense that when the decompression context information is used to decompress a header that was compressed with the compression context information, the original uncompressed header is reconstructed. Both the compression context information and decompression context information may be continuously updated by the compressor and decompressor respectively, based on the incoming headers, etc. However, the two contexts normally stay in synchronism.
When a mobile terminal is handed off to another radio cell served by another network entity, if no efficient procedure is defined to transfer the context information to the new network entity, the header compression/decompression process has to again proceed through reinitialization, which entails sending full headers in both the downlink traffic and the uplink traffic. Such a reinitialization with full headers is both disruptive of the ongoing communications and consumes the bandwidth over the air interface. The transfer of compression and decompression context information is a challenge because the compression/decompression process is asynchronous relative to and independent of the handoff process, since the former is driven by the flow of packets, while the latter is driven by the radio conditions. Hence, by the time the new network entity uses the transferred context information, it may already be out-of-synchronism with the contexts at the mobile terminal.
FIG. 1 illustrates the problem in the prior art involving transfer of compression and decompression context information associated with radio handoff. There is a non zero handoff preparation time (time ST1 to time ST2), during which the compression and decompression context information may be updated by the old network entity thus rendering the transferred value of the compression and decompression context information stale. Consequently, compression and decompression after the radio handoff is incorrect. In addition, the mobile terminal (MS) may be involved in information exchange, but transfer of information over the air interface should be kept to a minimum.
In RFC 2508, a short sequence number is included in each packet in order to detect error or packet loss. When the decompressor receives a header with a sequence number that is not consecutive from the previous one, packet loss is detected and a recovery scheme is employed to resynchronize the compressor and decompressor.
Just using a short sequence number to detect packet loss is not robust to an error-prone network, such as wireless network where `long loss` may happen frequently. Long loss is defined as the loss of `sequence cycle` or more packets in a row.
When long loss occurs, the sequence number in the packet received by decompressor `wraps around`. For example, assuming the sequence number consists of k bits, hence the sequence cycle equals to 2.sup.k packets. If 2.sup.k packets are lost in a row, the decompressor fails to detect the packet losses since it still sees consecutive sequence number in the incoming packets.
IP/UDP/RTP header compression schemes, as described for example in RFC 2508, S. Casner, V. Jacobson "Compressing IP/UDP/RTP Headers for Low Speed Serial Links, Internet Engineering Task Force, February 1999, which is incorporated herein by reference in its entirety, take advantage of the fact that certain information fields carried in the headers either 1.) do not change (`Type 1` header fields) or 2.) change in a fairly predictable way (`Type 2` header fields). Other fields, referred to as `Type 3` header fields, vary in such a way that they must be transmitted in some form in every packet (i.e. they are not compressible).
Examples of Type 1 header fields are the IP address, UDP port number, RTP SSRC (synchronization source), etc. These fields need only be transmitted to the receiver/decompressor once during the course of a session (as part of the packet(s) transferred at session establishment, for example). Type 1 fields are also called `unchanging` fields.
Examples of Type 2 header fields are the RTP timestamp, RTP sequence number, and IP ID fields. All have a tendency to increment by some constant amount from packet (n) to packet (n+1). Thus, there is no need for these values to be transmitted within every header. It is only required that the receiver/decompressor be made aware of the constant increment value, hereafter referred to as the first order difference (FOD), associated with each field that exhibits this behavior. Receiver/decompressor utilizes these FODs to regenerate up-to-date Type 2 field values when reconstructing the original header. Type 2 fields are part of `changing` fields.
It should be emphasized that, on occasion, Type 2 fields will change in some irregular way. Frequency of such events depends on several factors, including the type of media being transmitted (e.g., voice or video), the actual media source (e.g., for voice, behavior may vary from one speaker to another), and the number sessions simultaneously sharing the same IP-address.
An Example of a Type 3 header field is the RTP M-bit (Marker), which indicates the occurrence of some boundary in the media (e.g., end of a video frame). Because the media normally varies in unpredictable ways, this information cannot be truly predicted. Type 3 fields are part of `changing` fields.
The decompressor maintains decompression context information that contains all the pertinent information related to rebuilding the header. This information is mainly type 1 fields, FOD values, and other information. When packets are lost or corrupted, the decompressor can lose synchronization with the compressor such that it can no longer correctly rebuild packets. Loss of synchronization can occur when packets are dropped or corrupted during transmission between compressor and decompressor.
Given the above, the compressor needs to transmit three different types of headers during the course of a session:
Full Header (FH): Contains the complete set of all header fields (Types 1, 2, and 3). This type of header is the least optimal to send due to its large size (e.g., 40 bytes for IPv4). In general, it is desirable to send an FH packet only at the beginning of the session (to establish Type 1 data at the receiver). Transmission of additional FH packets has adverse effects on the efficiency of the compression algorithm. When the compressor transmits FH packets, it is said to be in the `FH state`. PA1 First Order (FO): Contains minimal header information (e.g. Type 3 fields), compressor/decompressor specific control fields (specific to the compression algorithm in use), and information describing changes in current FOD fields. An FO packet is basically an SO packet (described below), with additional information that establishes new FOD information for one or more Type 2 fields at the decompressor. If the header compression is being applied to a VoIP (voice over internet protocol) stream, transmission of an FO packet might be triggered by the occurrence of a talk spurt after a silence interval in the voice. Such an event results in some unexpected change in the RTP timestamp value, and a need to update the RTP time stamp at the receiver by a value other than the current FOD. The size of FO packets depends on the number of Type 2 fields whose first order difference changed (and the amount of the absolute value of each change). When the compressor transmits FO packets, it is said to be in the `FO state`. PA1 Second Order (SO): A SO packet contains minimal header information (e.g. Type 3 fields), and compressor and decompressor specific control fields. The preferred mode of operation for the compressor and decompressor is transmission and reception of SO packets, due to their minimal size (on the order of just 2 bytes or even less). When the compressor transmits SO packets, it is said to be in the `SO state`. SO packets are transmitted only if the current header fits the pattern of an FOD.